在一般的軟體公司，和面對規模的不大的專案，除非你是個對軟體開發、工程品質、效率 “真的” 有興趣，而且學習能力和產出，也可以跟上時程的工程師，或是進入這樣的團隊。不然你要面對的，可能是以下的環境和調性。

案子不大是什麼意思？差不多是程式碼低於 LOC 100K (Source lines of code, LOC) 的規模。至於 100K 這個數字是怎麼來的，只能說是經驗法則吧，差不多就是加班找 bug 會開始不爽、開始思考什麼是單元測試的數字。

那麼 LOC 100K 以下的案子，究竟有什麼造成 “有動力自主成長” 的門檻呢？

大部分的案子，直接使用 “quickstart guide” 的範例，就可以滿足功能需求

除了可以滿足需求，連帶也能達到效能及格門檻 (例如 C10K)。不過也因此在大部分的情況下，專案團隊不知道自己做了什麼，也不知道 “自己還不知道” 什麼事情。講的更明白一點，就是不知道系統什麼時候會壞掉、要怎麼弄壞自己的系統。

因為案子都不大，因此即使開發習慣不好，在時程、經費、客戶的耐心上，仍然有很大的容錯空間

意思是直接砍掉重練的成本，都遠低於導入良好開發習慣、方法；當然，也沒有了教育訓練的痛苦過程，不用去做違背人性的事情。我們都知道改變自己的習慣、學習新東西會讓大腦不舒服。

很忙、很卡，但是不會比嘗試不熟悉的工作方式不舒服

因此如果你正在低於 LOC 100K 的團隊，想要讓整個隊伍自主成長、動起來，開始學習用更優雅的方式工作，那會是非常困難的。即使是用實質的獎勵，或是用考績威脅 (更何況你可能沒這個權力)，都不一定能成功。站在主管或是老闆的立場，你弄了一個讓大家需要跨過適應期、會有一段時間不舒服的工作方式，能不能獲得效益還不知道，又要承擔人力流失的風險。